Designing complex user experience systems, such as web domains, requires a significant amount of thought regarding what should appear on different web pages. One approach is to first model the system using, e.g., a unified modeling language (UML). UML allows an analyst to utilize graphical representations to define “use cases” that will allow user goals to be met. Use cases may comprise any interaction that a user might have with the system, e.g., request a quote, browse special offers, save to a file, etc. Once a UML use case model is completed, a user experience designer can design web pages that appropriately enable the interactions for the users.
However, user experience designers need to understand the relationships users perceive among use cases to design an experience that enables users to interact effectively with a complex system in a way that meets their expectations. For instance, when does it make sense to include or not include different use cases and use case choices on the same page? When a designer creates views of the system that users interact with, the views are composites, derived from multiple use cases, offering the user multiple possible actions that may include executing a primary use case (e.g., purchase this item) as well as initiating other related, but not necessarily integral, use cases (e.g., view related items). Unfortunately, current UML modeling practices do not support formal specification of these relationships. Thus, a completed UML model provides little guidance to the designer regarding relationships among use cases.
Although UML does provide for defining certain types of use case relationships in which use cases directly depend upon each other, i.e., “includes” and “extends,” such relationships do not allow an analyst to formally establish associations among independent use cases, as described above. The “includes” relationship is used to indicate that as a natural part of executing one use case (A), another use case (B) is executed as a component of use case (A). The “extends” relationship describes a use case that adds unessential functionality to another use case. Accordingly, a need exists that will address shortcomings in the art.